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Abstract: In this paper , we compare existing software component technologies for embedded systes^^rai 
respect to requirements captured from the vehicle industry. The vehicular industry wants to ra»ke ^ree of 
the advantages with component based design ; however they also need to address non-functioja^^Jbperties 



of their products, such as reliability and timeliness. Several component technologies *<MTjJssing such 
properties have recently been proposed. In this paper, we present initial findings fr\ji an ongoing 
evaluation concerning some of these technologies with respect to the requiremen\^fcat£d by industrial 
actors. 

We conclude that none of the studied technologies is a perfect match forftJr^industrial requirements. 
Furthermore, no single technology stands out as being a significantly beter crfoice than the others; each 
technology has its own pros and cons /A) 

l Introduction ^C/Y 

During the last few years, component-based software engi«eermg for embedded real-time systems has 
received a large amount of attention in the research corqnw^ty. However, industrial software developers 
are still, to a large extent, using monolithic and platform^ep£ndent software development technologies. 

Often companies can achieve considerable busin^s|Ni^nefits in terms of reduced costs, shortened time -to- 
market and increased software quality by applyrng component-based software engineering. There is 
however significant risks and costs associafre^with the adoption of a new development technique. These 
must be carefully evaluated before introd^ca^in the development process. 

Our approach in this paper is to stua^^rne of the existing component technologies suitable for distributed 
embedded real-time systems, a|d to* compare these technologies with industrial requirements from 
manufacturers of heavy vehiclAJyl . The main purpose of this work in progress paper is to disclose our 
initial findings and to solrtit t^Jback on which techniques to study and what requirements are of interest. 



2 Industrial Requirements 



The benefits orS^^| a component based technique can be divided into two different aspects, the 
operational b^neS^ (e.g. analysability and portability) and the development benefits (e.g. reusability and 
maintainabil^^ The requirements on such a component based technique can, in the same way, be divided 
into tedaSh^l- and development requirements. 

/Cartjrom the requirements addressed in the paper, safety and robustness are evident requirements on a 
venHralar system. The system should function correctly in stressful environmental conditions and perform 
its required functions under stated conditions for a specified period of time without any catastrophic 
consequences to the environment. However, safety and robustness are not easy for a component technology 
to consider, since these requirements are mainly related to system design and implementation. 

The requirements are obtained from interviews with senior technical staff at two Swedish companies, CC 
Systems [l] and Volvo Construction Equipment [2]. These companies develop control software for large, 
low-series vehicles (e.g. wheel loaders and forest harvesters) and their systems are characterized as safety 
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critical distributed embedded real-time systems with limited hardware resources. 

Our definitions of the elicited requirements, listed below, include important aspects of the introduction of a 
component-based development technique. These definitions, including both technical merits and demerits, 
are somewhat different, or should be seen as an extension, of the generally used definitions. 

2.1 Technical Requirements 

Analysable - the chosen technique should be easy to analyse with respect to non -functional properties, 
such as the timing behaviour and the memory consumption. It is important to be able to both veri^^^tne 
tasks meet their deadlines and to be able to analyse the end-to-end timing behaviour of thfl»conTplete 
system. />0 

The components should be configured at compile - time, to make them smaller and^asieT^io analyse off- 
line. 



Modelling and Computation - based on information extracted during the iews, the technique 

should be based on a standard modelling language like UML [3]. The comffr^knts should preferably be 
passive, focusing on a pipe-and-filter computation model [4]. The reason tJWje that restrictive in the 
choices concerning the modelling and computations is related txf^Vat/irity and the use of mature 
techniques. 



d^^n 



Open - a component should be source code, i.e., no binaries. l^Tleasons for this include that companies 
are used to have access to the source code, to find functiotaal^errors, and enable support for white box 
testing. The possibility to look into the components daejjlwt necessary mean that you are allowed to 
modify them. 

Portable - the components, and the infrastructmgSfcrrounding them, should be platform independent to 
the highest degree possible. In order to suppoijypiatlxtrm independency, the components should not use the 
operating system primitives or the processorteaWes directly. This is an important requirement because of 
the frequently shifting hardware and opeawtfl^ system needs. 

Resource Constrained - the systeflS^Spnsidered, i.e. distributed embedded real-time systems, are usually 
resource constrained, when it cc^es to the CPU and the memories. Therefore, the software systems should 
be light-weighted and the comg^Jnts infrastructure should be minimised. 




2.2 Development Requirements 

Maintainable ^th^^Mponent should be easy to change and maintain, e.g., for use in new applications or 
environments y^^bose for which it was originally designed. 

IntroduciW^^he possibility for companies to gradually migrate into the chosen technique, not jumping 
in to tb/iS*!* technique to fast, is important, to make the change in technique as safe and inexpensive as 



lable - the components should be easy to reuse and the technique, and its supporting tools, should 
offer support for component version management. To have good support for version and variant 
management is a very important requirement, because it reduces the risk of reinventing components - after 
all, software reuse is one of the most important aspects when introducing a component based development 
technique. 

Understandable - the system should be easy to understand, to simplify evaluation, and verification both 
on the system level and on the component level. This should also include making the technology easy and 
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intuitive to use in a development project. 

3 Existing Component Technologies 

In this section, existing component technologies for embedded systems are described. The technologies 
considered originate both from academia and industry. The selection criterion for a component technology 
has firstly been that there is enough information available, secondly that the authors claim that the 
technology is suitable for embedded systems, and finally we have tried to achieve a combination of both 
research and industry examples. The technologies described and evaluated are PECT, Koala, RrfS^us 
Component Model, PBO, PECOS and CORBA. 

3.1 PECT sSO* 

vO 

Prediction-Enabled Component Technology (PECT) [5] is a development infrastructure trj|J: incorporates 
development tools and analysis techniques. PECT is an ongoing research pr&^W at the Software 
Engineering Institute (SEI) at Carnegie Mellon University. C ^ 

PECT defines that any component technology can be used if compositi^^suTes guarantee runtime 
properties, by enforcing that predictable construction patterns are used J^hfris allowed by a user, and 
what is required by the underlying component technology, is determuti^lbyjhe available analysis methods 
and prediction goals. ^J*^ 

PECT focuses mainly on analysis. Assumed that the prediction^^nework contain prediction techniques 
for the desired properties; a high grade is motivated on shisTequirement. PECT is also portable and 
introducible, because of its independence of the underlyiqjjJ^3janology. 



introflS^pif 



As PECT is highly analysable, portable and introflfc^pTe- it is not very understandable. In order to 
understand the model, the mapping to the underlvnra»:omponent technology must be understood as well. 

^(^^.2 Koala 

s^^bred for development of software in consumer electronics, and 



The Koala component technology 
it is developed and used by Philips 



Consumer electronics are oftermregfeurce constrained since they use cheap hardware to keep development 
costs low. Koala pays spe^a^raention to resource usage through a thread sharing technique. The thread 
sharing technique keeps tfiSfiumber of threads low, which in turn keep the memory utilisation low. The 
implementation is req^^with message queues which have a function to process messages in the context 
of a thread. 



fs B|i<oak 



All compone^KB|i<oala are source code components and are therefore totally open for inspection. This 
makes it e*s\pfor companies to find functional errors and enables white-box testing. The technology is 
also und^S^ndable; it builds on simple and mature techniques. 

/fcobjious problem with Koala, compared to the requirements is that it seems hard to gradually introduce 
thewchnology. Koala components are tightly coupled to the Koala compiler, and the underlying operating 
system. The components use the same interaction mechanisms in between each other's as towards the 
operating system. 

3.3 Rubus Component Model 

Rubus is developed byArcticus systems [8] and is, e.g., used by Volvo Construction Equipment. 
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The Rubus component model is tailored for resource constrained systems with real-time requirements. 
Rubus has a red and a blue part for hard and soft real-time respectively. The red kernel is used for time- 
critical applications and is therefore time - triggered. The blue kernel is event-triggered, and used for less 
time-critical applications. 

The computation model provided by Rubus is the desired pipe and filter model, very simple and suitable 
for control applications. Like Koala, Rubus also has source-code components. The components are hence 
open for inspection and white-box testing. 



operating system. 

3.4 PBO 



A requirement that is not met is the constraint of portability. The Rubus component model is too^ 
coupled to the Rubus operating system since it is shipped with, and developed on top ofyihe j 

<<2T 

Port Based Objects (PBO) [9] combines object oriented design, with port autorr^t^ theory. PBO was 
developed as a part of the Chimera RTOS project [10] at the Advanced Manipulatfartaboratory at Carnegie 
Mellon University. Together with Chimera, PBO forms a framework aimed forfifwlopment of sensor-based 
control systems, with specialisation in reconfigurable robotics applicatiqn^^ ^ 

An explicit design goal for a system based on PBO is to minimise coNm^lication and synchronisation, thus 
facilitating reuse. PBO is a simple and intuitive model which is hisClylmderstandable, both at system level 
and within the components themselves; hence the requirement <^«Jiaerstandability is satisfied. 

While PBO is very intuitive, it is also tightly coupled Mj^^ts RTOS, Chimera. Therefore it is hard to 
introduce parts of PBO in present system configuratio«ABe*:ause of the dependencies on the RTOS, 1 
1 not be considered very portable. 



^peri*in( 




PECOS [11] is a collaborative project befKs^r^industrial and research partners. The goal for the PECOS 
project is to enable component-based* Semiology for embedded systems, especially for field devices, i.e. 
embedded reactive systems . The prl^es^tries to consider non-functional properties very 
thoroughly in order to enable as^^meVit of the properties during construction time. 

There is no special run-titae^^lironment developed in the PECOS project. Instead there are requirements 
on platform independences at least on portability. 

The PECOS proiecj^Hujliilcorporated the Unified Modelling Language (UML) for modelling the system. This 
makes the modew^Jtorctive considering the requirement of model and computation. 

Furthermoae^HCOS is a research project and much focus has been put on non-functional properties such 
as memfl^^pnsumption, timeliness etc. which makes PECOS analysable . 

T^£ requirement of openness is not considered fulfilled, due to the fact that PECOS uses black-box 
com^nents. In later releases, the PECOS project is considering to use a more open component model [12]. 

3.6 CORBA Based Technologies 

The Common Object Request Broker Architecture (CORBA) is a standard that provides a set of rules for 
writing platform independent applications. The CORBA standard is developed by the Object Management 
Group (OMG) [13]. 
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A major drawback with CORBA is that it requires a lot of functionality in order to connect diverse 
platforms within a heterogenous system. Because of this, variants of CORBA exist, two major are Minimum 
CORBA [14] for resource constrains systems, and RT-CORBA [15] for time -critical systems. 

OMG has also defined a CORBA Component Model (CCM) . CCM extend the CORBA object model by 
defining features and services that enable application developers to implement, manage, configure and 
deploy components that integrate commonly used CORBA services. 

Because CORBA is a middleware architecture that defines communication between nodes, it ^ec/TI|es 
highly portable . While CORBA is portable, and powerful, it is also very run-time demanding. In (3CTIBA, 
bindings are performed during run-time. Therefore the requirement of analysability cannot be^ns^pered 
fulfilled. Dynamic binding is very computation intense; hence CORBA is not suitable^yf^^source 
constrained systems. CORBA is using binary components, i.e. the components are closed, a*a^|pection or 
white-box testing is out of the question. % 



4 Summary of Evaluation 



Table 1, shows a summary of the initial evaluation of component technologjeVfor embedded vehicular 
systems presented in the paper. The evaluation of the different technok>ai^s i^Dased on the requirements 
defined in section 2. 



3 = Good, the requirements are very well satisfied. 
2 = Satisfactory, the requirements are to some extent satisfied 1 
satisfied NA= Not Applicable, requirement is not addressed 
IN = Inconclusive, not determined 



Require. Technology Koala Rubus PECT 



Analysable 



Model and computation 



Open ^ 
Portable 



MSqWable 

cCv 

^AnV-oducible 

Reusable 



Understandable 



2 N, 




the requirements are not or very little 



Table 1: A summary showing how well existing component technologies fulfil industrial requirements. 

5 Conclusions and Future Work 
Our conclusion, based on the industrial requirements, is that there is no one component technology 



ICIEMS 2014 



ISBN : 978-81-925233-3-0 



w.edlib.asdf.res.in / w 



Proceedings of The Intl. Conf. on Information, Engineering, Management and Security 2014 [ICIEMS 2014] 308 



available that fulfils all the requirements listed in section 2. However, ; 
interesting techniques and concepts. 



e of the technologi 



We have noticed that, for a component technology to be fully accepted by industry, the whole systems 
development context needs to be considered. It is not only the technical properties, such as modelling, 
computation model, and openness, that needs to be addressed, but also development requirements like 
maintainability, reusability, and to which extent it is possible to gradually introduce the technology. It is 
however important to keep in mind that a component technology alone cannot be expected to solve all 
these issues. 



We will continue to investigate the industrial requirements in more detail, and also continue^© c^ptu 
requirements by cooperating with other industrial partners . We will also assess to what o^^^xisting 
technologies can be adapted in order to fulfil the requirements, or whether selected jra^^bf existing 
technologies can be reused if a new component technology needs to be developed. 
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